Fix Power BI Costs query type mismatch on VCPUs/vCores cast - #2305
Draft
Michael Flanakin (flanakin) wants to merge 2 commits into
Draft
Fix Power BI Costs query type mismatch on VCPUs/vCores cast#2305Michael Flanakin (flanakin) wants to merge 2 commits into
Michael Flanakin (flanakin) wants to merge 2 commits into
Conversation
…orage Costs query The storage-based Costs query cast tmp_VMvCPUs/tmp_SQLvCores (extracted from the x_SkuDetails JSON blob) straight to Int64.Type. Rows where that field isn't a clean number -- e.g. Marketplace/SaaS, reservation purchase, or other non-VM/SQL charge rows -- produced an Error value that surfaced as an OLE DB "Type mismatch (DISP_E_TYPEMISMATCH)" error during refresh once enough months/rows were pulled in. Switched to Table.TransformColumns with a try/otherwise guard, matching the existing x_SkuTerm defensive-cast pattern (PR #2175), so an unparseable value degrades to null instead of failing the refresh. Fixes #2297
microsoft-github-policy-service
Bot
requested a review
from Brett Wilson (MSBrett)
September 8, 2026 02:05
|
@Michael Flanakin (@flanakin), thanks for the PR. It looks like you forgot to indicate whether the documentation was updated as part of the PR. Please edit the PR to select (x) the appropriate items in the checklist. This PR will be blocked until one of the values is selected. |
|
@Michael Flanakin (@flanakin), thanks for the PR. It looks like you forgot to indicate whether the documentation was updated as part of the PR. Please edit the PR to select (x) the appropriate items in the checklist. This PR will be blocked until one of the values is selected. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🛠️ Description
The storage-based Power BI
Costsquery casttmp_VMvCPUs/tmp_SQLvCores(values extracted from the free-formx_SkuDetailsJSON blob) straight toInt64.TypeviaTable.TransformColumnTypes. That blob's shape varies by charge type (VM usage, Marketplace/SaaS purchase, reservation purchase, etc.), so on a row where theVCPUs/vCoresfield isn't a clean number, the cast produced anErrorvalue instead of throwing during query evaluation. When that error-valued cell was loaded into the model as anInt64column, Power BI surfaced it during refresh as:A single month often has no such rows, so it refreshes fine; a full-year refresh pulls in the row that trips it, matching the report.
This switches the cast to
Table.TransformColumnswith atry ... otherwise nullguard, mirroring the existing defensive pattern used forx_SkuTerm(#2175) — an unparseable or missing value now degrades tonullinstead of failing the whole refresh.Fixes #2297
📷 Screenshots
N/A (Power Query/M change, no visual change)
📋 Checklist
🔬 How did you test this change?
No automated test coverage exists for Power Query/M logic in this repo, and I don't have a Power BI Desktop environment connected to the reporter's storage account to reproduce the failure live, so this hasn't been verified against real failing data. I read through the full
Costs.tmdlM query and confirmed theTable.TransformColumnTypescall at the reported line is the only unguarded numeric cast on a value sourced from the SKU details JSON blob, and confirmed the replacementTable.TransformColumnssyntax is valid M.📦 Deploy to test?
🙋♀️ Do any of the following that apply?
📑 Did you update
docs/changelog.md?📖 Did you update documentation?
🤖 Generated with Claude Code